By

  阅读数： 次

前言

目前学习了下Dubbo 和 Spring Cloud，并且在简单学习后，总结了下这两者之间简单的区别；如果以后有需要搭建分布式系统的需求，可以根据这两者之间的区别，再根据当前公司的业务等情况选择最为合适的来搭建自己的分布式系统。

Dubbo+Zookeeper vs Spring Cloud：

框架比较的方面 Dubbo+Zookeeper Spring Cloud
性能方面 Dubbo是阿里巴巴开源的顶级项目，以前是用于阿里巴巴的分布式服务治理框架,其性能毋庸置疑一定是很强的，它适合一些比较大的公司用的分布式服务治理框架。（注：2017年之前阿里巴巴没有对其进行更新维护，但是2017年Dubbo项目官网宣布重新对其进行更新维护，并且在2018年Dubbo项目正式进入了Apache孵化器） Spring Cloud是最近才兴起的一个分布式服务框架，现在它的社区十分的火爆，代码的更新迭代十分的快；它一般适合于中小型企业，并且性能比Dubbo低一些；
具有的特点 Dubbo有良好的连通性、健壮性、伸缩性、升级性。结合Dubbo可以相对于单体系统提升系统整体的扩展性。
Dubbo提供了多种协议给用户选择， 如dubbo、hessian、rmi 。 并可为每个服务指定不同的传输协议，粒度可以细化到方法， 不同服务在性能上适用不同协议进行传输，比如大数据用短连接协议，小数据大并发用长连接协议。		 Spring Cloud来源于Spring，质量、稳定性、持续性都可以得到保证。
Spirng Cloud天然支持Spring Boot，更加便于业务落地。
Spring Cloud是Java领域最适合做微服务的框架。
相比于其它框架,Spring Cloud对微服务周边环境的支持力度最大。
方便性 Dubbo使用起来不太方便，由于许多组件其本身不支持，所以我们在搭建架构环境时，需要集成一些其他的开源组件，集成时会遇到种种的困难，并且在以后的项目维护和升级也不方便。
Dubbo服务调用的方式是RPC，服务提供方与调用方接口依赖方式太强：我们需要将调用的抽象接口依赖到消费者项目中才能调用服务，这会导致在以后的开发、测试、版本管理上很麻烦。		 pringCloud自身的组件可以搭建成一个完整的微服务架构，并且搭建起来稍微简单一些；
SpringCloud调用的方式是REST，REST接口相比RPC更为轻量化，服务提供方和调用方的依赖只是依靠一纸契约，不存在代码级别的强依赖，当然REST接口也有缺点，很容易导致定义文档与实际实现不一致导致服务集成时的问题。
灵活性 由于dubbo许多组件都是集成的第三方，所以dubbo组件之间的自由度很高，dubbo更加的灵活。 SpringCloud自身支持了组件，各个组件之间的关联关系已经配置好了，所以它的灵活度不是很好，如果想要用第三方组件代替其中的一个组件的话会有一些困难。
服务注册中心 Zookeeper保证C(一致性)P(分区容错性)。
当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。		 Eureka保证A(可用性)P(分区容错性)。
Eureka各个节点都是平等的，几个节点挂掉不会影响正常工作。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)
代码开发角度 Dubbo常与Spring、zookeeper结合，而且实现只是通过xml来配置服务地址、名称、端口，代码的侵入性是很小的，可以说几乎没有代码入侵。 Spring Cloud，由于它的实现需要类注解等，所以多少具有一定代码侵入。

总结：

总的来说这两个搭建分布式系统的框架各有各的好处，在选择时要根据自己的需求等情况综合做选择；
但是Eureka作为单纯的服务注册中心来说感觉要比Zookeeper更加“专业”，因为注册服务更重要的是高可用性，可以接受短期内达不到一致性的状况。

注：可能此文章中表格内容看起来不太舒服，你还可以参考我在CSDN中的这篇文章。

❤不要忘记留下你学习的足迹 [点赞 + 收藏 + 评论]嘿嘿ヾ

一切看文章不点赞都是“耍流氓”，嘿嘿ヾ(◍°∇°◍)ﾉﾞ！开个玩笑，动一动你的小手，点赞就完事了，你每个人出一份力量(点赞 + 评论)就会让更多的学习者加入进来！非常感谢！￣ω￣=